What

Adds support for Plausible custom event properties (event:props:<name>) across the query tools, generically — property names aren't hardcoded, so any site can query whatever its own tracker sends.

• Break down by a custom property: get_breakdown accepts a dimension of event:props:<name> (e.g. event:props:plan) alongside the standard dimensions.
• Filter by a custom property on every query tool (get_breakdown, get_timeseries, get_conversions, compare_periods) via a new property_filters input, e.g. [{ "property": "plan", "operator": "is", "values": ["pro"] }]. Operators: is, is_not, contains, contains_not; entries combine with AND.

Why

Sites commonly attach custom properties to events (plan tier, outbound link target, etc.). The tools could previously only reach the built-in dimensions, so those segments were unreachable through the MCP.

Approach

Shared dimensionSchema, propertyFiltersSchema, and buildPropertyFilters live in src/schemas.ts; each tool wires property_filters in the same way it already handles page/goal. The server instructions now document the event:props: convention to steer clients away from malformed queries. Kept focused: no new tools, no changes to existing query shapes.

Test plan

In an MCP client pointed at a server for a site that sends custom properties:

• Ask for a breakdown by one of its custom properties (e.g. "break down visitors by plan") and confirm rows are grouped by that property's values.
• Ask to filter a query by a custom property value (e.g. "daily visitors where plan is pro") and confirm the numbers are scoped to that value.
• Confirm existing queries (top pages, sources, conversions, period comparisons) are unchanged.